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Abstract  -  Ontologies  are  becoming  increasingly  popular 
due  to  recent  efforts  to  extend  the  capabilities  of  the  World 
Wide  Web  through  the  addition  of  formal  semantics.  While 
ontologies  have  traditionally  been  used  as  precise  languages 
to  facilitate  efficient  exchange  of  information  among  peo¬ 
ple,  the  “Semantic  Web”  is  extending  this  role  to  software 
agents.  For  this  to  be  possible,  ontologies  must  be  for¬ 
malized  in  languages  processable  by  computers,  such  as 
OWL,  the  W3C’s  Web  Ontology  Language.  The  purpose 
of  OWL  ontologies  is  to  permit  software  agents  to  under¬ 
stand  web  content  and  to  interact  intelligently  with  Web 
services  (which  may  themselves  be  software  agents).  The 
use  of  such  ontologies,  however,  need  not  be  constrained  to 
the  Web.  Recently,  ontologies  have  found  their  way  into 
higher-level  information  fusion  where  they  are  providing  a 
means  for  describing  and  reasoning  about  sensor  data,  ob¬ 
jects,  relations  and  general  domain  theories.  To  the  best  of 
our  knowledge,  there  is  as  of  yet  no  documented  effort  to 
capture  the  main  uses  of  ontologies  in  information  fusion. 
In  this  paper  we  start  filling  this  void  by  presenting  a  num¬ 
ber  of  “use  cases,”  i.e. ,  scenarios  of  the  use  of  ontologies  in 
the  context  of  higher-level  information  fusion.  In  this  paper 
we  develop  use  cases  in  which  ontologies  are  used  both  for 
the  fusion  process  itself  and  for  the  development  of  fusion 
systems.  The  use  cases  cover  scenarios  in  which  the  agent 
roles  are  played  by  people,  software  or  both. 

Keywords:  Information  fusion,  ontology,  use  cases,  system 
development,  consistency  checking,  querying 

1  Introduction 

An  ontology  is  a  formulation  of  the  entities  that  are  rel¬ 
evant  to  a  domain  as  well  as  the  relationships  between 
these  entities.  Ontologies  originated  in  philosophy,  but 
they  are  increasingly  being  used  in  many  scientific  and 
engineering  domains.  The  traditional  use  of  ontologies 
is  to  serve  as  precise  languages  to  facilitate  efficient  ex¬ 
change  of  information  among  people.  Recently,  ontolo¬ 
gies  have  begun  to  be  used  for  communication  among 
software  agents.  Indeed,  it  has  long  been  recognized 


that  independently  developed  software  agents  can  com¬ 
municate  only  if  they  have  a  shared  understanding  of 
the  meaning  of  the  data  being  exchanged.  Ontologies, 
especially  formal  ontologies,  are  an  effective  means  by 
which  two  software  agents  can  acquire  such  a  shared 
understanding. 

Fusion  systems  combine  information  acquired  from 
multiple  sources.  When  the  sources  are  very  similar 
(e.g.,  two  sensors  of  exactly  the  same  type  in  different 
locations)  and  the  fusion  task  is  highly  limited  (e.g., 
tracking  objects),  then  there  is  no  strong  argument  for 
introducing  ontologies.  However,  if  the  sources  are  dis¬ 
similar  or  the  fusion  tasks  are  more  diverse,  then  on¬ 
tologies  can  be  more  effective  than  ad  hoc  techniques. 

Although  many  ontology  languages  have  been  pro¬ 
posed,  the  one  that  is  emerging  as  the  standard  is  the 
Web  Ontology  Language  (OWL)  of  the  World  Wide 
Web  Consortium.  OWL  is  the  basis  for  the  pro¬ 
posed  “Semantic  Web,”  which  is  a  layer  above  the 
current  Web,  that  supports  semantic  understanding 
of  Web  content.  The  original  purpose  of  OWL  on¬ 
tologies  was  to  permit  software  agents  to  understand 
Web  content  and  to  interact  intelligently  with  Web 
services  (which  may  themselves  be  software  agents). 
The  use  of  ontologies,  however,  is  not  limited  to  the 
Web,  and  ontologies  have  recently  been  introduced  into 
higher-level  information  fusion  where  they  provide  a 
mechanism  for  describing  and  reasoning  about  sensor 
data,  objects,  relations  and  general  domain  theories 
(cf.  [1,  2,  3,  4,  5,  6,  7,  8,  9]). 

The  use  of  ontologies  in  general  has  been  addressed 
by  Jasper  and  Uschold  [10]  and  [11].  Usage  scenarios 
and  goals  for  ontologies  in  general  have  been  developed 
in  the  context  of  the  Ontology  Definition  Metamodel 
standardization  effort  [12].  The  World  Wide  Web  Con¬ 
sortium  has  also  developed  scenarios  for  the  use  of  on¬ 
tologies  as  part  of  its  Semantic  Web  effort  [13]. 

In  this  article,  we  present  some  of  the  main  uses 


Report  Documentation  Page 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 

1.  REPORT  DATE 

2006 

2.  REPORT  TYPE 

3.  DATES  COVERED 

00-00-2006  to  00-00-2006 

4.  TITLE  AND  SUBTITLE 

5a.  CONTRACT  NUMBER 

Use  Cases  for  Ontologies  in  Information  Fusion 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Air  Force  Rome  Laboratories, Rome  Research  Site, Rome, NY, 13441 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR'S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

The  original  document  contains  color  images. 

14.  ABSTRACT 

see  report 

15.  SUBJECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 

ABSTRACT 

18.  NUMBER 

OF  PAGES 

7 

19a.  NAME  OF 

RESPONSIBLE  PERSON 

a.  REPORT 

unclassified 

b.  ABSTRACT 

unclassified 

c.  THIS  PAGE 

unclassified 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


of  ontologies  in  information  fusion.  The  uses  are  for¬ 
malized  using  “use  cases”  which  capture  the  common 
features  of  classes  of  usage  scenarios.  In  Section  2  we 
introduce  the  concept  of  an  ontology  and  describe  the 
main  constructs  of  OWL.  The  concept  of  a  use  case 
is  discussed  in  Section  3  which  also  introduces  the  no¬ 
tation  most  commonly  used  for  drawing  use  case  dia¬ 
grams.  We  then  present  the  two  main  uses  of  ontolo¬ 
gies  in  information.  In  Section  4  we  give  the  use  case 
for  ontology  based  information  fusion  processing.  This 
use  case  is  concerned  with  the  use  of  ontologies  while 
a  fusion  system  is  processing  data.  A  specific  scenario 
is  presented  that  shows  how  ontologies  facilitate  the 
ability  to  evaluate  very  general  queries  as  a  fusion  sys¬ 
tem  is  running.  Ontologies  can  also  be  used  during  the 
development  of  a  fusion  system.  This  use  of  ontologies 
is  discussed  in  Section  5.  One  specific  use  of  ontologies 
for  software  development  is  to  verify  the  correctness 
of  the  software,  and  a  scenario  illustrating  this  is  pre¬ 
sented  in  this  section.  There  are  many  other  uses  of 
ontologies  in  information  fusion  that  are  not  covered 
by  these  two  use  cases.  Some  of  these  are  mentioned 
in  Section  6  which  concludes  the  paper. 

2  Ontologies 

An  ontology  is  an  explicit,  formal,  machine-readable 
semantic  model  that  defines  the  classes  (or  concepts) 
and  their  possible  inter-relations  specific  to  some  spec¬ 
ified  domain  [14].  To  construct  an  ontology  one  must 
have  an  ontology  specification  language,  of  which  there 
are  several  to  choose  from.  Many  forces  are  driving  the 
increasing  interest  in  ontologies,  but  one  that  is  rapidly 
gaining  momentum  is  the  emergence  of  web-enabled 
agents  [14] .  These  agents  can  reason  about  and  dynam¬ 
ically  integrate  the  appropriate  knowledge  and  services 
at  run-time  based  on  formal  ontologies.  Ontologies  are 
also  the  basis  for  the  Semantic  Web  [15],  where  they 
are  being  used  to  create  machine-readable,  semantic- 
descriptions  of  Web  content  that  can  be  shared,  com¬ 
bined  and  reasoned  about  automatically  by  theorem 
provers  and  intelligent  agents. 

As  part  of  its  Semantic  Web  effort,  the  W3C  has 
been  engaging  in  the  development  a  new  XML-based 
language  called  the  Web  Ontology  Language  (OWL) 
[16].  OWL  is  an  emerging  standard  for  ontologies 
and  knowledge  representations,  based  on  the  Resource 
Description  Framework  (RDF)  [17]  and  the  DARPA 
Agent  Markup  Language  (DAML),  which  is  the  im¬ 
mediate  predecessor  of  OWL.  OWL  is  a  declarative, 
formally  defined  language  that  fully  supports  special¬ 
ization/generalization  hierarchies  as  well  as  arbitrary 
many-to-many  relationships.  Both  model  theoretic 
and  axiomatic  semantics  have  been  fully  defined  for  the 
elements  in  OWL/DAML  providing  strong  theoretical 
as  well  as  practical  benefits  in  terms  of  being  able  to 
precisely  define  what  can  and  cannot  be  achieved  with 
these  languages.  The  field  is  relatively  young,  yet  sev¬ 
eral  tools  have  been  developed  and  many  more  are  on 


the  horizon  for  creating  OWL  ontologies  and  process¬ 
ing  OWL  documents.  In  our  work,  we  create  ontologies 
as  UML  diagrams  and  then  programmatically  convert 
them  into  DAML/OWL  representations  [18]. 

Ontologies  capture  potential  objects  and  potential 
relations;  that  is  to  say,  they  do  not  describe  what 
is  in  the  world  but  rather  what  can  be  in  the  world. 
Ontologies,  however,  can  be  used  to  annotate  or  mark¬ 
up  descriptions  of  instances  of  the  world  in  what  are 
called  instance  annotations. 

It  should  be  noted  that  the  job  performed  by  on¬ 
tology  languages  cannot  be  accomplished  with  purely 
syntactic  languages  such  as  XML  Schema.  An  XML 
Schema  specification  can  define  the  structure  of  ob¬ 
jects  (i.e.,  their  composition)  but  it  cannot  capture  the 
semantic  meaning  implicit  in  the  relations  that  might 
exist  between  objects.  To  do  this  requires  knowledge 
about  how  the  classes  of  data  objects  relate  to  one 
another.  This  type  of  knowledge,  called  meta-data 
(i.e.,  data  about  data  relationships),  is  what  ontologies 
capture.  With  appropriate  meta-knowledge  to  explain 
how  the  data  is  to  be  interpreted,  intelligent  systems 
can  reason  about  the  data  and  make  inferences  that 
can  be  proven  to  be  correct.  It  is  this  power  that  makes 
ontologies  critical  to  our  formal  approach  to  situation 
awareness  and  fusion. 

2.1  Examples  of  Ontologies 

In  this  paper  we  use  two  small  pieces  of  the  Situation 
Awareness  Ontology  that  we  have  developed  in  our  re¬ 
search.  The  first  one  is  shown  in  Figure  1.  This  is  a 
UML  [19]  representation  of  an  ontology.  It  does  not  in¬ 
clude  all  the  details  which  can  be  represented  in  an  on¬ 
tology  representation  language,  like  OWL  [16].  While 
the  OWL  representation  is  appropriate  for  computer 
consumption,  the  UML  representation,  on  the  other 
hand,  is  more  appropriate  for  humans.  The  aspects 
captured  in  this  UML  representation  include  classes, 
subclasses  and  associations.  Classes  are  represented  as 
boxes.  Each  class  defines  a  “type”,  i.e.,  it  describes 
instances  that  have  some  characteristics  in  common. 
In  particular,  it  means  that  instances  are  linked  to  in¬ 
stances  of  other  classes  according  to  the  properties, 
which  in  this  diagram  are  shown  as  arrows.  A  hollow 
arrow  represents  a  special  property  called  subclass. 

So  in  Figure  1  we  see  ten  classes  and  fourteen  proper¬ 
ties,  one  of  them  being  the  subclass  property  (Situation 
is  a  subclass  of  Object).  Situation  is  the  central  class  in 
this  ontology.  According  to  this  ontology,  a  situation 
must  have  a  Goal.  This  is  specified  by  the  fact  that 
the  Situation  class  is  associated  with  the  Goal  class 
and  that  this  property  has  a  multiplicity  constraint 
of  1..*,  i.e.,  there  must  be  at  least  one  goal  instance 
for  any  situation  instance.  A  situation  also  includes 
some  objects  and  relations  among  them.  The  fact  that 
Situation  is  a  subclass  of  Object  indicates  that  every 
instance  of  Situation  is  also  an  instance  of  Object.  In 
other  words,  situations  themselves  are  objects.  This 
is  a  very  important  aspect  of  representing  situations, 


since  it  means  that  situations  can  have  attributes  and 
properties  like  any  other  object.  Following  through 
the  diagram  we  can  see  that  relations  consist  of  rela¬ 
tion  tuples.  Moreover,  we  can  see  that  objects  have 
attributes,  which  are  attribute  tuples.  The  tuples  con¬ 
sist  of  attribute  type  and  attribute  value.  The  value, 
in  turn,  is  determined  by  the  value  function,  which  is 
expressed  with  respect  to  a  unit. 

Figure  1  also  indicates  that  the  value  of  an  attribute 
or  a  relation  is  defined  by  events.  Events  are  further 
represented  in  Figure  2.  According  to  the  Event  sub¬ 
ontology  events  are  part  of  an  event  stream.  Each 
event  in  an  event  stream  is  associated  with  one  or  more 
objects.  Objects  then  have  attributes,  as  we  already 
stated  above. 

3  Use  Case  Formalism 

Most,  if  not  all,  software  being  developed  these  days  is 
object-oriented.  The  software  development  phases,  ac¬ 
cording  to  software  engineering  rules,  include  specifica¬ 
tion,  design,  implementation,  testing  and  maintenance. 
According  to  the  software  engineering,  software  is  first 
modeled,  then  implemented  and  tested.  The  software 
engineering  community  came  to  an  agreement  to  use 
a  common  modeling  language  -  the  Unified  Modeling 
Language  (UML)  [19].  As  the  first  step  in  the  modeling 
of  a  newly  developed  software  system,  most  developers 
model  the  aspects  of  the  interaction  of  the  system  with 
the  external  environment  using  use  case  diagrams.  In 
this  paper  we  use  this  modeling  formalism  of  the  UML 
to  show  the  role  of  ontologies  in  information  fusion. 
But  first  we  need  to  introduce  this  formalism. 

Use  case  modeling  uses  three  main  representational 
icons:  the  oval  to  represent  a  use  case,  the  straw  man 
to  represent  an  actor  and  lines  that  connect  actors  with 
use  cases,  use  cases  with  other  use  cases,  or  actors 
with  other  actors.  Lines  can  end  with  arrow  heads. 
Two  types  of  arrow  heads  are  used,  possibly  with  some 
adornments.  A  use  case  captures  some  part  of  the  func¬ 
tionality  of  the  system.  For  instance,  “Collect  Sensory 
Data”  could  be  such  a  functionality.  Actors  can  be 
either  humans  interacting  with  the  system  or  other 
systems  that  are  not  part  of  the  system  being  mod¬ 
eled.  More  precisely,  actors  don’t  represent  specific 
individuals  but  rather  roles  played  by  either  humans 
or  other  systems.  A  line  between  an  actor  and  a  use 
case  represents  the  fact  that  the  actor  is  involved  in 
the  use  case.  When  the  line  ends  with  an  arrow  head, 
it  means  that  the  element  on  the  opposite  side  of  the 
arrow  head  initiates  the  use  case.  If  the  arrow  is  a 
hollow  arrow,  this  means  that  the  element  at  the  op¬ 
posite  side  of  the  hollow  arrow  head  is  a  special  case 
(a  subtype)  of  the  element.  For  instance,  one  use  case 
can  be  a  special  kind  of  another  use  case.  Moreover, 
lines  can  have  adornments  enclosed  in  guillemots  that 
represent  stereotypes.  In  use  case  diagrams  the  only 
stereotypes  used  are  ((include))  and  ((extend)).  The 
((include))  stereotype  means  that  the  use  case  at  the 
arrow  head  always  includes  the  function  of  the  other 


side’s  use  case.  The  ((extend))  stereotype  represents 
the  fact  that  the  use  case  at  the  arrow  head  is  a  func¬ 
tionality  that  is  executed  sometimes,  and  thus  repre¬ 
sents  an  exception  rather  than  the  rule. 

4  Use  Case:  Ontology  Based  Fusion 

Possibly  the  most  common  use  of  ontologies  in  informa¬ 
tion  fusion  is  for  the  fusion  processing  itself.  The  use 
case  diagram  is  shown  in  Figure  3.  The  use  case  for  fu¬ 
sion  in  general  is  shown  at  the  top  of  this  figure  using 
the  oval  labeled  with  “Fusion”.  This  use  case  repre¬ 
sents  the  various  forms  of  fusion  scenario  in  which  var¬ 
ious  sources  of  information  are  processed  in  response 
to  requests  by  one  or  more  users.  The  sources  of  infor¬ 
mation  can  be  sensors,  Level2+  processes,  databases 
and  documents.  These  are  all  collectively  referred  to 
as  data  authors. 

The  annotations  at  the  ends  of  the  edges  represent 
the  number  of  instances  of  the  actor  that  can  partic¬ 
ipate  in  the  use  case.  The  symbol  1..*  near  the  User 
actor  means  that  there  must  be  at  least  one  user  par¬ 
ticipating  in  the  fusion  use  case.  The  first  number  is 
the  lower  limit  on  the  number  of  participants  and  the 
second  number  is  the  upper  limit  on  the  number  of 
participants.  An  asterisk  means  that  there  is  no  upper 
limit . 

The  Fusion  use  case  is  the  general  case  of  a  fusion 
process  which  may  or  may  not  use  ontologies.  Those 
scenarios  that  use  ontologies  are  represented  by  the 
Ontology  Base  Fusion  use  case.  This  use  case  has  two 
additional  actors.  There  must  be  an  ontology  (or  set 
of  ontologies).  This  is  represented  by  the  Fusion  On¬ 
tology  actor.  There  can  also  be  other  ontology  based 
systems  (which  may  or  may  not  be  fusion  systems). 
When  another  ontology  based  system  is  participating, 
it  acts  like  a  Data  Author,  except  that  ontologies  may 
be  used  to  achieve  interoperability.  By  contrast,  for 
most  Data  Authors,  it  is  entirely  the  responsibility  of 
the  fusion  system  to  understand  the  formats  and  pro¬ 
tocols  that  are  produced  by  the  Data  Authors.  This  is 
a  significant  advantage  of  ontology  based  systems. 

Another  important  feature  of  ontology  based  fusion 
is  represented  by  the  remaining  three  use  cases  in  the 
diagram.  These  three  use  cases  are  concerned  with 
querying  the  fusion  system  as  it  is  running.  The  basic 
use  case  is  called  Querying,  and  it  includes  two  others: 
the  sending  of  the  query  and  the  process  of  inferring 
the  answer.  Inference  is  a  logical  reasoning  process 
which  requires  a  theorem  prover  or  rule  based  system. 
Querying  can  be  done  by  either  a  user  or  another  on¬ 
tology  based  system. 

One  could  argue  that  the  query  capability  could  be 
implemented  in  a  fusion  system  without  the  use  of  an 
ontology.  While  it  is  true,  such  a  query  capability 
would  be  limited  to  the  procedures  that  were  hard¬ 
coded  into  the  fusion  process.  For  instance,  one  might 
list  a  number  of  queries  and  then  write  procedures  for 
answering  each  of  the  queries.  The  ontology  based  ap¬ 
proach  is  different.  An  ontology  based  system  is  as- 


Attribute 


attributeType 


AttributeTuple 


Situation 

hasGoal 

\ 

Goal 

z-' 

1..* 

hasObject  \  f  y 


hasRelation 


Object 


Relation 


hasAttiibuteTuple 


onObject 

(ordered) 


hasValue 


ValueFunction 


hasRelationTuple 


RelationTuple 


hasTmthValue 


parti  allyDefinedBy 


Event 


Fig.  1:  SAW  Core  Lite  Ontology 


Fig.  2:  SAW  Event  Ontology 


sumed  to  have  a  generic  reasoner  that  can  answer  any 
query  that  can  be  formulated  in  the  language  defined 
by  the  ontology.  In  general,  the  number  of  possible 
queries  that  can  be  formulated  in  the  language  defined 
by  an  ontology  is  infinite.  Obviously,  this  kind  of  a 
capability  cannot  be  implemented  using  a  procedural 
approach. 

Consider  the  situation  awareness  ontology  shown  in 
Figure  1.  It  is  easy  to  imagine  some  of  the  queries  that 
might  be  asked.  For  example,  one  might  be  interested 
in  determining  the  objects  which  are  located  in  a  par¬ 
ticular  region,  or  one  might  want  to  know  the  physical 
units  of  the  attributes  possessed  by  the  objects  in  a 
particular  aggregate  (grouping  of  objects).  Still  other 
examples  would  involve  various  forms  of  inference.  One 
might  be  interested  in  the  location  of  an  aggregate  of 
objects.  While  objects  have  locations,  aggregations  of 
them  do  not  directly  have  locations.  This  must  be 
inferred  from  the  relationship  between  the  objects  and 
the  aggregate  (sometimes  called  the  “part-of”  relation¬ 
ship).  Any  of  these  queries  (and  many  others)  could 
be  expressed  procedurally.  However,  one  would  have 


to  design  and  develop  a  new  procedure  for  each  one. 
Ontology  based  systems  have  a  significant  advantage 
over  traditional  systems  in  this  regard. 

The  use  of  the  word  “query”  is  somewhat  mislead¬ 
ing  because  it  suggests  that  one  is  one  concerned  with 
retrieving  information.  The  intention  is  that  one  can 
not  only  retrieve  information  but  also  modify  informa¬ 
tion.  This  use  of  the  word  is  consistent  with  how  it 
is  used  in  databases.  The  ability  to  modify  a  running 
system  is  a  significant  new  feature  of  ontology  based 
systems.  Of  course,  all  systems  include  some  parame¬ 
ters  that  can  be  specified  while  the  system  is  running. 
Ontology  based  systems  can  be  modified  in  any  man¬ 
ner  that  is  specified  by  the  ontology.  While  this  can 
be  done  procedurally,  each  such  modification  must  be 
developed  separately.  Once  again,  the  ontology  based 
systems  have  the  advantage. 

5  Use  Case:  Development  of  Ontology 
Based  Fusion  Systems 

Information  fusion  systems  are  complex  systems  that 
require  a  substantial  development  effort.  Ontologies 
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Fig.  3:  Fusion  Use  Case 


can  help  assure  that  the  fusion  system  correctly  sat¬ 
isfies  its  specifications.  The  use  case  diagram  for  fu¬ 
sion  system  development  is  shown  in  Figure  4.  The 
three  main  use  cases  in  this  diagram  are  System  De¬ 
velopment,  Fusion  System  Development  and  Ontology 
Based  Fusion  System  Development.  The  first  use  case 
captures  some  of  the  characteristics  of  general  case 
software  system  development.  The  actors  in  this  use 
case  are  Application  Developer  and  Domain  Expert. 
The  Application  Developer  represents  the  engineers 
who  are  developing  the  hardware  and  software  of  the 
fusion  system.  The  Domain  Expert  represents  the  in¬ 
dividuals  who  provide  the  domain-specific  expertise  for 
the  system. 

The  diagram  shows  that  the  Fusion  System  Develop¬ 
ment  use  case  is  a  special  case  of  System  Development. 
Developing  a  fusion  system  requires  fusion  specific  fea¬ 
tures  to  be  developed,  such  as  data  association  and 
fusion  rules.  These  features  along  with  their  incorpo¬ 
ration  into  the  overall  system  are  developed  by  a  Fusion 
Expert. 

Ontology  based  fusion  system  development  is  a  spe¬ 
cial  case  of  general  fusion  system  development  which 
adds  a  number  of  optional  features.  This  use  case 
has  three  additional  actors:  Fusion  Ontology,  Ontology 
Reasoning  Tool,  System  Database.  Unlike  the  actors 
discussed  so  far,  none  of  these  new  actors  would  every 
be  a  person.  The  Fusion  Ontology  actor  is  the  ontology 
(or  set  of  ontologies)  that  form  the  basis  for  informa¬ 
tion  fusion  in  the  domains  of  interest.  It  is  represented 
as  an  actor  because  it  is  normally  developed  separately, 
and  therefore  is  external  to  the  system  being  devel¬ 


oped.  In  a  sense,  it  plays  a  similar  role  to  a  database, 
except  that  it  is  used  to  store  meta-information  about 
the  system  being  developed.  In  particular,  it  keeps  in¬ 
formation  about  the  types  (classes)  of  inputs  to  the  fu¬ 
sion  system,  the  types  of  outputs  from  the  system,  and 
possibly  the  types  of  information  items  that  are  passed 
among  the  components  of  the  system  (applicable  when 
the  system  consists  of  a  number  of  components) .  Addi¬ 
tionally,  this  ontology  has  information  about  the  types 
of  objects  that  the  system  will  represent  and  the  types 
of  relationships  (properties)  that  will  be  implemented 
and  maintained  by  the  system.  As  development  pro¬ 
ceeds,  instances  of  these  types  and  properties  are  in¬ 
troduced  and  can  be  stored  in  a  repository  represented 
in  the  diagram  by  the  System  Database  actor. 

The  Ontology  Reasoning  Tool  actor  is  responsible 
for  formal  reasoning  tasks  such  as  inference,  querying, 
consistency  checking  and  code  generation.  The  first  of 
these,  inference,  is  always  present  in  any  use  of  ontolo¬ 
gies.  The  others  are  optional  features,  and  so  they  are 
linked  to  the  Ontology  Based  Fusion  System  Develop¬ 
ment  use  case  by  means  of  the  ((extend))  connector. 

Queries  to  the  System  Database  are  more  power¬ 
ful  than  ordinary  database  queries  because  they  make 
use  of  inferencing  carried  out  by  the  Ontology  Reason¬ 
ing  Tool.  The  query  can  involve  any  of  the  types  and 
properties  in  the  ontology.  One  can,  for  example,  ask 
whether  the  inputs  to  the  system  are  consistent  with 
the  specifications.  One  can  also  determine  whether 
software  (source  code)  is  consistent  with  the  ontology. 
It  is  even  possible  to  generate  some  or  all  of  the  code  for 
the  system  from  the  information  and  meta-information 
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provided  by  the  Fusion  Ontology  and  System  Database 
actors. 

Here  is  an  example  of  software  verification  using  on¬ 
tologies.  A  fusion  system  based  on  the  ontology  in 
Figure  2  had  a  class  Event  that  looked  like  this: 

public  class  Event  - 
private  int  event  Count  =  0; 


The  event  count  was  incremented  by  1  each  time 
that  an  event  was  constructed.  The  Event  class  com¬ 
piled  correctly  and  even  passed  various  tests.  However, 
it  is  incorrect  because  the  eventCount  should  be  an  at¬ 
tribute  of  the  EventStream  class,  not  the  Event  class. 
The  intention  was  that  the  eventCount  was  a  mecha¬ 
nism  for  assigning  event  identifiers  for  the  events  in  a 
stream  of  events.  The  initial  implementation  was  as¬ 
signing  the  same  identifier  to  every  event  in  an  event 
stream. 

6  Conclusion 

Ontologies  are  an  increasingly  important  mechanism 
for  integration  of  disparate  software  systems,  and  they 
are  also  beginning  to  be  used  in  information  fusion 
systems.  In  this  paper  we  showed  some  of  the  main 
current  and  potential  uses  of  ontologies  in  information 
fusion.  In  both  cases  there  are  significant  advantages 
for  using  introducing  ontologies  that  are  either  difficult 
to  achieve  or  even  impossible  without  ontologies.  The 


advantages  include  support  for  interoperability,  flexi¬ 
ble  querying,  run-time  modifiability,  validation  against 
specifications  and  consistency  checking. 

There  are  still  many  other  possibilities  for  the  use 
of  ontologies  in  information  fusion  that  are  not  cov¬ 
ered  by  the  two  use  cases  that  were  presented.  Sys¬ 
tems  that  do  not  share  a  single  ontology  might  still 
be  able  to  interoperate  by  mapping  or  merging  ontolo¬ 
gies.  It  may  be  possible  to  construct  systems  that  not 
only  use  ontologies  but  also  modify  them  or  even  learn 
them  dynamically.  We  are  currently  working  toward 
the  development  of  tools  that  can  achieve  these  goals. 
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